支付系统的总架构!
推荐关注
扫码关注“后端架构师”,选择“星标”公众号
重磅干货,第一时间送达!
责编:架构君 | 来源:六脉神剑
链接:juejin.cn/post/7101522332883091463
责编:架构君 | 来源:六脉神剑
链接:juejin.cn/post/7101522332883091463
上一篇好文:网站都变成灰色,有哪些方法可以快速实现?
大家好,我是后端架构师。
前言
种一棵树最好的时间是十年前,其次是现在
中国互联网支付总架构
今天这篇文章就是想带大家来了解下一个从点到点,从端到端,从始到终的支付链路,最近三只松鼠的坚果不是挺火的嘛,那六六就以从京东买三只松鼠为例,带大家从整个宏观的角度来看看中国的互联网支付!
小六六要买三只松鼠,那么首先我得找一个电商平台,这边用的是京东,所以最开始的话我们接触的可能是一个电商平台 选好东西之后,六六这边就要去下单,下单完成之后,进入到了京东的收银台了,京东的收银台,包含了京东支付,微信支付,云闪付等等,支付宝目前还没看到,这些属于第三方支付,这些支付方式在中国都是需要支付牌照的。 那么这些支付方式其实接的是我们商业银行的支付通道,然后通过支付通道到了我们的银联和网联 最后到达我们的中国人民银行,也就是我们常说的央妈!绝对的食物链的顶端,所以一笔小小的支付都是经过这么多的参与方的
来看看京东支付的架构
其实这几秒钟整个支付的链条跋山涉水,翻山越岭经历千险,
支付架构解析
我们看上面的架构图,对于一个服务平台的支付架构,一般有图中的相关系统组成:直面用户的收银台,记录业务的订单系统,推动交易的交易系统,对支付指令进行处理的支付系统,支付指令传送通道的支付通道子系统。
另外支付成功后还有一条线清结算线:支付成功以后交易将数据提交清算中心完成数据的清分计算,然后提交账务系统完成记账;再通知会计核心完成内部账的记录;最后通知资金平台对交易向商家进行货款的结算……
这样对于一个服务平台来说,一个支付的骨架就出来了!
其实很多第三方支付公司都是这么玩的 你比如说国内的京东支付,微信支付,海外的Paypal,Strip checkout等等。另外,搜索公众号Linux就该这样学后台回复“猴子”,获取一份惊喜礼包。
支付系统架构
支付系统的主要职责是处理业务系统发起的所有交易请求,包含收银台、交易系统、支付核心等模块,根据各模块不同的功能职责,可以将支付系统分为业务层和支付层两部分。
业务层负责为业务系统提供收付款的操作界面以及处理业务系统提交的交易请求; 支付层负责通过支付渠道实时处理完成资金的收付款、记录参与交易的账户间资金流转情况并按照预定规则对账户所属资金进行拆分与合并。
收银台
收银台即用户日常付款前选择渠道的页面,是支付平台提供的基本功能之一, 主要职责是协助业务平台完成支付交易,向用户提供一致的交易体验。一般情况下,根据不同终端类型定制标准化的收银台给到外部进行调用,保证各终端体验一致且针对各端特定需求、场景来展现不同的支付方式。
收银台的业务场景(边界) 一般分为付款与充值两部分:付款即通过各类支付方式针对业务订单发起付款,例如:用户在天猫店购买一件衣服,确认订单后自动跳转至支付宝,引导用户选择对应的方式(余额、花呗、银行卡等)进行付款。 充值即用户对账户进行余额充值,例如:用户登录支付宝、微信或其他商户自有钱包系统对账户余额进行充值。
交易核心
交易系统本身是作为支付系统外部处理业务逻辑的外围系统。由于支付核心系统本身并非面向业务端且业务逻辑的多变性与复杂性,支付系统为了兼顾稳定并能够为业务端提供灵活支持,因此需要在支付系统外层搭建面向业务端处理交易逻辑的交易系统。交易系统处理业务端的各种交易类型后,将业务信息转化为支付系统可识别的支付订单并导入。
以担保交易为例,C 端用户在天猫购买一件商品,成功支付后商家进行发货,用户确认收货后平台将货款结算给商家。此处设计到「担保交易支付」以及「确认收货」环节,与支付系统内部的支付与结算步骤一一对应:
用户付款成功后对应交易的付款成功状态; 用户确认收货后对应交易的成功状态。
从支付和收货缓解可以看出,担保收单交易就是讲支付系统的支付基础能力包装后对外支持业务的一款产品。
会员系统
会员系统是完整的支付平台内极其重要的基础模块之一,负责管理支付系统内部的交易主体。会员系统保存了客户在支付系统内部账号的实体信息,为客户建立了统一的、以会员 ID 为标识的会员基本信息、关系信息(会员和账户、会员和操作人、会员与银行卡)视图。
一般情况,会员在支付系统内部分为个人会员和企业会员(默认企业会员有商户权限),以电商平台为例,C 端用户为个人会员,B 端商户为企业会员:通常,企业会员会配置一定的业务参数,比如结算周期、接口权限、支付方式配置等(开通商户权限的情况下); 在大多数互联网公司,支付系统仅需要对接支付渠道的模块,在没有独立平台化的情况下,不太会出现需要独立的账户体系。
支付核心
支付系统的职责为通过支付核心与后端清结算、会计、账务等系统的统一协作,让前端支付产品可以更关注产品本身的逻辑,而减少对清分、对账、储值等后端服务的考量及动作;同时通过标准化的支付指令定义,统一前端支付产品的支付请求接口,提供适应各类产品使用的基础支付服务。
支付核心的边界:
支付服务:负责对后端支付系统的接口进行业务包装,同时实现使用多个支付方式进行组合支付的功能;
支付服务流程:对各支付类型的支付服务流程进行定义,具体定义为充值、提现、内转支付(转账)、退款等原子类型,并实现对基础服务的流程编排;
支付指令:发起订单后,通过协议和协议明细项加工得出支付指令,需具备进行后续操作处理的全部要素信息;
支付协议:根据产品设立支付协议,因此支付协议的关键要素包含产品码及支付编码,定义着产品的处理流程、收付款信息、对应的支付渠道信息。
账务核心
账务核心的功能为,根据前端业务系统的要求设计相匹配的账户类型、管理各类账户、记录账户资金变动等,同时,按照公司内部的财会规范提供反映各账户间交易资金变化情况的会计数据;并且负责将自身记录账务流水与支付渠道结算资金和结算流水进行核对,对对账结果中出现的差错交易进行差错处理。
清算核心
清算核心负责维护客户参与交易时的清分、结算规则,并按照已配置的规则完成交易资金的清分与结算操作。
结束
由此可见如果你要做一个第三方支付公司的,大大小小估计得建设几十个系统呢?所以来说,支付并不简单!
欢迎大家进行观点的探讨和碰撞,各抒己见。如果你有疑问,也可以找我沟通和交流。扩展:接私活儿
上一篇好文:网站都变成灰色,有哪些方法可以快速实现?
大家好,我是后端架构师。
前言
种一棵树最好的时间是十年前,其次是现在
中国互联网支付总架构
小六六要买三只松鼠,那么首先我得找一个电商平台,这边用的是京东,所以最开始的话我们接触的可能是一个电商平台 选好东西之后,六六这边就要去下单,下单完成之后,进入到了京东的收银台了,京东的收银台,包含了京东支付,微信支付,云闪付等等,支付宝目前还没看到,这些属于第三方支付,这些支付方式在中国都是需要支付牌照的。 那么这些支付方式其实接的是我们商业银行的支付通道,然后通过支付通道到了我们的银联和网联 最后到达我们的中国人民银行,也就是我们常说的央妈!绝对的食物链的顶端,所以一笔小小的支付都是经过这么多的参与方的
来看看京东支付的架构
其实这几秒钟整个支付的链条跋山涉水,翻山越岭经历千险,
支付架构解析
另外支付成功后还有一条线清结算线:支付成功以后交易将数据提交清算中心完成数据的清分计算,然后提交账务系统完成记账;再通知会计核心完成内部账的记录;最后通知资金平台对交易向商家进行货款的结算……
这样对于一个服务平台来说,一个支付的骨架就出来了!
其实很多第三方支付公司都是这么玩的 你比如说国内的京东支付,微信支付,海外的Paypal,Strip checkout等等。另外,搜索公众号Linux就该这样学后台回复“猴子”,获取一份惊喜礼包。
支付系统架构
支付系统的主要职责是处理业务系统发起的所有交易请求,包含收银台、交易系统、支付核心等模块,根据各模块不同的功能职责,可以将支付系统分为业务层和支付层两部分。
业务层负责为业务系统提供收付款的操作界面以及处理业务系统提交的交易请求; 支付层负责通过支付渠道实时处理完成资金的收付款、记录参与交易的账户间资金流转情况并按照预定规则对账户所属资金进行拆分与合并。
收银台
收银台即用户日常付款前选择渠道的页面,是支付平台提供的基本功能之一, 主要职责是协助业务平台完成支付交易,向用户提供一致的交易体验。一般情况下,根据不同终端类型定制标准化的收银台给到外部进行调用,保证各终端体验一致且针对各端特定需求、场景来展现不同的支付方式。
收银台的业务场景(边界) 一般分为付款与充值两部分:
付款即通过各类支付方式针对业务订单发起付款,例如:用户在天猫店购买一件衣服,确认订单后自动跳转至支付宝,引导用户选择对应的方式(余额、花呗、银行卡等)进行付款。 充值即用户对账户进行余额充值,例如:用户登录支付宝、微信或其他商户自有钱包系统对账户余额进行充值。
交易核心
交易系统本身是作为支付系统外部处理业务逻辑的外围系统。由于支付核心系统本身并非面向业务端且业务逻辑的多变性与复杂性,支付系统为了兼顾稳定并能够为业务端提供灵活支持,因此需要在支付系统外层搭建面向业务端处理交易逻辑的交易系统。交易系统处理业务端的各种交易类型后,将业务信息转化为支付系统可识别的支付订单并导入。
以担保交易为例,C 端用户在天猫购买一件商品,成功支付后商家进行发货,用户确认收货后平台将货款结算给商家。此处设计到「担保交易支付」以及「确认收货」环节,与支付系统内部的支付与结算步骤一一对应:
用户付款成功后对应交易的付款成功状态; 用户确认收货后对应交易的成功状态。
会员系统
会员系统是完整的支付平台内极其重要的基础模块之一,负责管理支付系统内部的交易主体。会员系统保存了客户在支付系统内部账号的实体信息,为客户建立了统一的、以会员 ID 为标识的会员基本信息、关系信息(会员和账户、会员和操作人、会员与银行卡)视图。
通常,企业会员会配置一定的业务参数,比如结算周期、接口权限、支付方式配置等(开通商户权限的情况下); 在大多数互联网公司,支付系统仅需要对接支付渠道的模块,在没有独立平台化的情况下,不太会出现需要独立的账户体系。
支付核心
支付系统的职责为通过支付核心与后端清结算、会计、账务等系统的统一协作,让前端支付产品可以更关注产品本身的逻辑,而减少对清分、对账、储值等后端服务的考量及动作;同时通过标准化的支付指令定义,统一前端支付产品的支付请求接口,提供适应各类产品使用的基础支付服务。
支付核心的边界:
支付服务:负责对后端支付系统的接口进行业务包装,同时实现使用多个支付方式进行组合支付的功能;
支付服务流程:对各支付类型的支付服务流程进行定义,具体定义为充值、提现、内转支付(转账)、退款等原子类型,并实现对基础服务的流程编排;
支付指令:发起订单后,通过协议和协议明细项加工得出支付指令,需具备进行后续操作处理的全部要素信息;
支付协议:根据产品设立支付协议,因此支付协议的关键要素包含产品码及支付编码,定义着产品的处理流程、收付款信息、对应的支付渠道信息。
账务核心
账务核心的功能为,根据前端业务系统的要求设计相匹配的账户类型、管理各类账户、记录账户资金变动等,同时,按照公司内部的财会规范提供反映各账户间交易资金变化情况的会计数据;并且负责将自身记录账务流水与支付渠道结算资金和结算流水进行核对,对对账结果中出现的差错交易进行差错处理。
清算核心
结束
由此可见如果你要做一个第三方支付公司的,大大小小估计得建设几十个系统呢?所以来说,支付并不简单!
欢迎大家进行观点的探讨和碰撞,各抒己见。如果你有疑问,也可以找我沟通和交流。扩展:接私活儿
欢迎有需要的同学试试,如果本文对您有帮助,也请帮忙点个 赞 + 在看 啦!❤️
在 GitHub猿 还有更多优质项目系统学习资源,欢迎分享给其他同学吧!
PS:如果觉得我的分享不错,欢迎大家随手点赞、转发、在看。
最后给读者整理了一份BAT大厂面试真题,需要的可扫码加微信备注:“面试”获取。
欢迎有需要的同学试试,如果本文对您有帮助,也请帮忙点个 赞 + 在看 啦!❤️
在 GitHub猿 还有更多优质项目系统学习资源,欢迎分享给其他同学吧!
PS:如果觉得我的分享不错,欢迎大家随手点赞、转发、在看。
最后给读者整理了一份BAT大厂面试真题,需要的可扫码加微信备注:“面试”获取。
版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢!
版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢!
END
最近面试BAT,整理一份面试资料《Java面试BAT通关手册》,覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。在这里,我为大家准备了一份2021年最新最全BAT等大厂Java面试经验总结。
别找了,想获取史上最全的Java大厂面试题学习资料
扫下方二维码回复「面试」就好了
历史好文:
基于SpringBoot 的CMS系统,拿去开发企业官网真香
世界上最快的内存数据库横空出世,比 Redis 快 25 倍,Star 数飙升,杀疯了!
马斯克认错:裁掉他们是我最大的错误,但黑粉们却没能笑太久...
Spring Boot+JWT+Shiro+MyBatisPlus 实现 RESTful 快速开发后端脚手架!
一款分布式敏捷开发系统,支持服务治理、监控和追踪,适合中小型企业开发解决方案!
扫码关注“后端架构师”,选择“星标”公众号
别找了,想获取史上最全的Java大厂面试题学习资料
扫下方二维码回复「面试」就好了
历史好文:
基于SpringBoot 的CMS系统,拿去开发企业官网真香
世界上最快的内存数据库横空出世,比 Redis 快 25 倍,Star 数飙升,杀疯了!
马斯克认错:裁掉他们是我最大的错误,但黑粉们却没能笑太久...
Spring Boot+JWT+Shiro+MyBatisPlus 实现 RESTful 快速开发后端脚手架!
一款分布式敏捷开发系统,支持服务治理、监控和追踪,适合中小型企业开发解决方案!
扫码关注“后端架构师”,选择“星标”公众号